2014년 10월 22일 글을 블로그 마이그레이션과 함께 복원, 내용을 수정함.
다음 링크는 우리회사 기술 블로그 readme에 소개된 redis 클러스터링을 위한 twemproxy 소개 자료다.
http://readme.skplanet.com/?p=13477
이와 거의 똑같은 기능을 하는 moxi라는 프락시가 있다. 이하 moxi를 설명한다.
couchbase에서 받을 수 있다. 깃헙도 검색하면 나온다.
http://www.couchbase.com/kr/video/membase-and-moxi
memcached는 그 자체로 클라이언트가 컨시스턴시 해싱을 통해 분산을 지원하므로 서버만 클라이언트 사이드에서 추가하면 분산 환경이 구축된다. 단 moxi를 이용하면 서버를 모두 등록할 필요없이 L4로 2-3중화한 moxi만 바라보면 된다.
memcached는 분산 환경에서 이종 언어간에 문제가 좀 있다. 어제 이 문제로 검색을 좀 해보니 스택오버 플로에도 간간히 등장하는 소재다. 어제 반나절 정도 테스트 해 본 결과 경우의 수를 엄청 조합해 보아도 잘 안 됐다.
분산 memcached에서는 해싱 알고리즘에 따라 데이터가 각자의 주인을 찾아서 저장된다. 그런데 이종언어간 memcached 라이브러리들이 해싱을 조금씩 다르게 쓰는 것 같다. 그래서 다음과 같은 현상이 발생한다.
C로 돌아가는 1번 서버에서 저장한 값이 PHP로 돌아가는 2번 서버에서 안 읽힌다. 3번 서버의 자바에서는 읽히고 자바에서 쓴 값이 C에선 안 읽히고 뭐 그런다. 각각의 멤캐시를 뒤져보면 잘 저장되어 있다.
설정 미스로 생각하고 해싱 알고리즘과 분산정책, 라이브러리 종류를 바꿔보았으나 100% 힛트를 만족시키지는 못했다.
그냥 인터페이스 파서 프락시를 짭시다! 하는 와중에 moxi라는 것을 발견했다. moxi는 couchbase에서 제공하는 memcached 프락시다.
하는 일로 봐서는 소스 몇 줄이면 될 것 같은데 빌드도 어렵고 뭐 좀 그렇다. cmake 귀찮다고. 나는 그냥 make 파인디.. 바이너리를 받아서 씁시다 -_-;
완전한 transparent proxy다. 이 용어가 업계 통용어인지는 모르겠는데 10년도 전에 나에게 네트워크 지식을 전수해주신 이동범 지니네트웤스 소장님의 교육 이후로 나는 이 용어를 즐겨쓴다. 개발자는 moxi 데몬을 memcached 데몬이라고 생각하고 쓰면 된다. moxi를 다중으로 띄워놓는 경우에도 완전히 메쉬한 n:n 관계로 맵핑되므로 fail-over 에도 강하다고 할 수 있다. 더 정확히는 실험해봐야 하겠다.
포트가 다른 memcached n개, moxi n개를 띄워놓고 telnet cli 인터페이스 상에서 정상 set/get이 수행되었다.
/opt/moxi/bin/moxi -z 20000=localhost:11211,localhost:11212
소스도 공개되어있고, 간단하니 직접 구현하거나 개조해 봄직한 프락시다. 파트너는 memcached 뿐만 아니라 다른 인메모리 디비를 붙이는 것도 어렵지 않을 것이다.
최근인지 원래였는지는 모르겠지만 vBucket-aware를 지원한다는 말이 있다. 이것을 지원하면 컨시스턴시 해싱의 문제점, 즉 서버가 추가되거나 제거될 때 키의 물리적 위치가 변동되면서 캐시 미스가 발생하는 문제가 해결되는 모양이다. 캐시 미스 정도야 큰 문제가 아닐 수 있지만 저장소로 사용할 때는 문제가 된다. 이에 대해서는 조금 더 리서치가 필요하다.
http://www.couchbase.com/wiki/display/couchbase/Types+of+Couchbase+Clients